IBIS Macromodel Task Group Meeting date: 30 November 2010 Members (asterisk for those attending): Agilent: * Fangyi Rao * Radek Biernacki Ansoft: Chris Herrick Danil Kirsanov Ansys: * Samuel Mertens Dan Dvorjak Deepak Ramaswamy Cadence Design Systems: Terry Jernberg * Ambrish Varma Celsionix: Kellee Crisafulli Cisco Systems: * Mike LaBonte Stephen Scearce * Ashwin Vasudevan Ericsson: Anders Ekholm IBM: * Greg Edlund Intel: Michael Mirmak LSI Logic: Wenyi Jin Mentor Graphics: * John Angulo Vladimir Dmitriev-Zdorov Zhen Mu * Arpad Muranyi Micron Technology: Randy Wolff Nokia-Siemens Networks: * Eckhard Lenski Sigrity: Brad Brim Kumar Keshavan * Ken Willis SiSoft: * Walter Katz Mike Steinberger * Todd Westerhoff ST Micro: Syed Sadeghi Teraspeed Consulting Group: Scott McMorrow * Bob Ross TI: * Casey Morrison Vitesse Semiconductor: Eric Sweetman Xilinx: Mustansir Fanaswalla The meeting was lead by Arpad Muranyi ------------------------------------------------------------------------ Opens: - Introduction of new members: - Deepak Ramaswamy is making sure his tool follows the standard - Dan Dvorjak is trying to be more involved in IBIS developments - Sam Mertens has joined before, trying to follow AMI progress - Arpad: We will not meet Dec 27, returning Jan 4 -------------------------- Call for patent disclosure: - none ------------- Review of ARs: - Arpad update Version BIRD: - Done and Posted - Arpad update Typos BIRD: - Done and Posted - Removed use of "deprecated" ------------- New Discussion: Arpad showed the Typos BIRD draft: - Fangyi: - Page 2 & 140: Can we combine these together? - Bottom of Page 4: If a branch is a leaf it can't have a sub-branch - Walter: Yes, we have that rule - Arpad: This would be a good list discussion - Page 5: We should say the DLL strings are only In or InOut - Arpad: Out should be allowed - Todd: Reserved_Parameters are Info, not passed to DLL - Fangyi: Res Par are not In or InOut - Todd: We should take this out - Walter: The fact it is two sections only matters to the AMI file - Please send comments to Arpad Arpad showed the Version BIRD draft: - Bob: Is this posted? - Arpad: It is in our archive section - Arpad showed the ATM archive page - Arpad showed Version_BIRD_2.txt - Fixes were highlighted - Todd: There should be an example - It should show how to express strings - Bob: The BIRD template has an example section - Should it be InOut? - Todd: It should be Info - Arpad: It could be passed in for checking - Mike: It would be good to pass Info to the DLL for checking - Walter: It would be better to just create an In, not pass AMI_Version - Todd: Anything could be declared Model_Specific for this - Fangyi: AMI_Version is reserved? - This was verified in the BIRD - Ken: Is this a problem for IBISCHK - Bob: We will maintain 5.1 forever - IBISCHK has to support checking of every major version - This time we will retain support for a minor version, 5.1 - In documentation we might tag parameters by which version introduced them - Fangyi: Are separate IBIS_Version and AMI_Version a problem for the parser? - Todd: It knows how to check every version - Bob: We will never fix the 5.0 version because it is flawed - We should clarify that a higher DLL versions will support lower AMI files - Todd: Why are they not a matched set? - Radek: We see no reason to separate them - Arpad: The need for this was related to the flow diagram - Walter: In 5.0 strings do not have to be double quoted - In 5.1 they do - Arpad: We had other reasons too - Todd: The question is why we would support different IBIS versions in AMI files - Walter: If IBIS updates old AMI models might not work - Todd: We don't have to use new versions - No one has to change to avoid using double quotes - Walter: IBIS has a rule that you can bump up IBIS_Version with no problem - Todd: I wouldn't do that if it will break it - Arpad: There is a specific problem with 5.0 - Radek: If you don't need 5.1 IBIS features, don't use 5.1 - Ken: Why not put IBIS_Version in the AMI file? - Arpad: AMI_Version also serves for deprecation of AMI features - Ken: This may be dangerous - Todd: The expectation is that IBIS_Ver can be increased and nothing changes - There is no benefit in that - Old models can be passed off as new - Doing the same in AMI perpetuates a bad practice - We should not hold AMI files to the same rule - Arpad: We are not ready to vote on this - Bob: There are several reasons for doing it, but somewhat mushy - It's like .pkg files - Ken: But .pkg files use IBIS_Version - Walter: Touchstone is independent - Todd: We are trying to - Provide model longevity - Provide problem fixing - Improve parts of the spec that are dead - Ambrish: It should be OK as long as it is clear to developers - Bob: We do not require 5.0 files to have any 5.0 features - Default and Value can be used together in 5.0 - That has been deprecated - Format is technically illegal in 5.0, but it is supported by the parser - Todd: Some models will pass 5.0 but changing them to say 5.1 they will fail - Arpad: If we link AMI to IBIS_Version existing models will have to be updated - Todd: Or they stay at 5.0 - Why carry this baggage for eternity? - Ambrish: We should be able to keep a model at 5.0 - Arpad: To use analog features 5.1 will be needed - Then you lose the ability to use AMI 5.0 - At least .pkg and .ebd files have this own IBIS_Version fields - Walter: We are spending a lot of time to discuss something that is not so important ------------- Next meeting: 07 November 2010 12:00pm PT Next agenda: 1) Typos BIRD draft 2) Version BIRD draft 3) BIRD 121-124 discussions ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives